Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000131_owner-urn-ietf _Tue Nov 12 09:50:05 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA19325 for urn-ietf-out; Tue, 12 Nov 1996 09:50:05 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA19320 for <[e-mail]>; Tue, 12 Nov 1996 09:50:03 -0500
Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA00786  (mail destined for [e-mail]); Tue, 12 Nov 96 09:49:55 -0500
Received: from  jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C)
    id AA06815; Tue, 12 Nov 96 15:54:58 +0100
Received: by  jrc.it (5.x/EB-950213-L)
    id AA05259; Tue, 12 Nov 1996 15:49:40 +0100
Date: Tue, 12 Nov 1996 15:49:40 +0100
From: "Dirk.vanGulik" <[e-mail]>
Message-Id: <9611121449.AA05259@ jrc.it>
To: [e-mail], [e-mail]
Subject: Re: [URN] I18N does not belong in URNs
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
Reply-To: "Dirk.vanGulik" <[e-mail]>
Errors-To: [e-mail]

> >The reason for _not_ allowing any octet in the string after urn: is to
> >avoid entering into the dark realm of having to retrive MIB like display
> >strings whenever you encounter a URN you've not seen before; and which
> >you would like to display to a human in such a way he/she can still
> >transcribe it. Just showing a list of two digit hex numbers would not do.

> Realistically, how often should we expect a resource that we _can_ read to
> be expressed by a URN that we can't read (i.e. the URN needs the %XX
> encoding convention)?  I would maintain that this would be the unusual case.

> If (as an example) a Chinese information provider wished to make available
> their resources to English speakers as URNs, I would suspect they would want
> to provide "English-compatible" URNs, rather than long, seemingly random
> %XX-encoded strings.  Conversely (and for example), an Austrailian
> information provider that wants to market their information to native Arabic
> speakers (who are not necessarily English speakers) would want to provide
> their URNs in an "Arabic-compatible" form, rather than the foreign-looking
> English alphabet.

Well, that would be an expectation of something which resembles 'URL's on steroids;
my, personal, take on this is a bit different. We are seeing all sorts of collections
being opened up; each with some kind of local identifier or control number; often
closely tied to the language and habits of the -original- maintainers. A lot of the
'objects' in these collections have different views, depending on who you are, what
you have paid, what your preferences and access permisisons are.

So quite quickly you end up with the identifier of say a Technical Maintenance
document of a, say, phillips KT52 TV frame or a the left wing SPL bolt installation
a manual of a MD123 aeroplane. Which just happens to be avaible in quite a few
languages. Although for the original maintainers there might be a language in
which the local control identifier beared some relevance, but for most users
that relation is gone (and it was based on obsuce 8 char abbreviattions anyway).

> Although I would expect content-negotiation to be used on URNs, if the URN
> resource is to be used widely by the native speaker of a language, it would
> be better expressed in a form compatible with their native language.

Yes; that is a common human desire; worth allowing for. Which means some kind
of transcription of a reasonable number of languages and charset. Which still
are compatible with all others. Hence my simplified (and optional) Base64 kind
of encoding for name-schemes which need this.

> Otherwise, we might as well go with sequences of random digits.

Well; that is certainly what they conceptually could be to an 'alien' from
Mars; or a native japanese only speaker. And there is nothign wrong with that.

Dw.